[Rule Tuning] Rapid Secret Retrieval Attempts from AWS SecretsManager #5291
+80
−44
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This rule is quite loud in telemetry. However over 80% of alerts come from a single cluster, which seems to have a lot of role usage and operation-type IAM Users which assume other roles constantly. This makes me think the majority of these alerts may be from multiple role sessions retrieving secrets, rather than a single user retrieving multiple secrets rapidly. I've looked at the prod telemetry data we have access to and found a few instances where a single secret is accessed multiple times or certain AWS services retrieve multple secrets rapidly. All of these instances have been accounted for in the tunings here. - query has been changed to remove `GetBatchSecretValue` from the query since this API call actually calls the `GetSecretValue` for each of the secrets it's retrieving. So we only need to look for `GetSecretValue` - I've added the AWS services found in prod data that contribute to rapid secret retrieval - Changed the threshold parameters to look for a single `user.id` retrieving more than 20 unique secret values (`aws.cloudtrail.request_parameters`) - updated the description and investigation guide - reduced execution window
imays11
requested review from
Aegrah,
shashank-elastic,
terrancedejesus and
w0rk3r
imays11
added
Integration: AWS
Contributor
Rule: Tuning - GuidelinesThese guidelines serve as a reminder set of considerations when tuning an existing rule. Documentation and Context
Rule Metadata Checks
Testing and Validation
|
| field = ["user.id"] | ||
| value = 1 | ||
| [[rule.threshold.cardinality]] | ||
| field = "aws.cloudtrail.request_parameters" |
Contributor
There was a problem hiding this comment.
Based on docs there could be VersionId or VersionStage in the request. Maybe we use aws.cloudtrail.flattened.request_parameters.secretId instead?
Contributor
Author
There was a problem hiding this comment.
Trying to avoid using flattened fields unless absolutely necessary. I believe it is still valuable to alert if multiple versions and stages of a secret are being retrieved, so not sure it's necessary to eliminate these scenarios by using the flattened field. I didn't see any instances of this in the prod data cluster so it seems to be rare behavior maybe worth capturing. What do you think? @terrancedejesus
terrancedejesus
approved these changes
Nov 10, 2025
Aegrah
approved these changes
Nov 11, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request
Issue link(s):
Summary - What I changed
This rule is quite loud in telemetry. However over 80% of alerts come from a single cluster, which seems to have a lot of role usage and operation-type IAM Users which assume other roles constantly. This makes me think the majority of these alerts may be from multiple role sessions retrieving secrets, rather than a single user retrieving multiple secrets rapidly. I've looked at the prod telemetry data we have access to and found a few instances where a single secret is accessed multiple times or certain AWS services retrieve multple secrets rapidly. All of these instances have been accounted for in the tunings here.
GetBatchSecretValuefrom the query since this API call actually calls theGetSecretValuefor each of the secrets it's retrieving. So we only need to look forGetSecretValueuser.idretrieving more than 20 unique secret values (aws.cloudtrail.request_parameters)How To Test
There's a duplicated version of this rule in our test stack with the updated query and threshold values.
This script will allow you to test 3 different scenarios:
BatchGetSecretValue(updated rule should still alert onGetSecretValuecalls)script: trigger_credential_access_rapid_secret_retrieval_attempts_from_secretsmanager.py
Screenshot of initial rule capturing multiple instances of a single secret being retrieved
Screenshot of
BatchGetSecretValueAPI call preceded by multipleGetSecretValuecallsScreenshot of original rule capturing all 3 test scenarios vs. updated rule capturing only the expected 2 scenarios